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1 

2 FIELD OF THE INVENTION 

3 

4 The present invention relates to computer program products and methods 

5 for interfacing a calling application and one or more callable applications. 
6 

7 BACKGROUND OF THE INVENTION 
8 

9 Interfacing different software applications is a general problem in the field 

10 of software technology, since called applications typically require application- 

11 specific and proprietary calls and attributes (data) and respond by returning 

12 data based on an application-specific and proprietary data model. 

13 The interfacing of different application also becomes a more and more 

14 important issue in the World Wide Web (WWW). Although the WWW has ini- 

15 tially been user-oriented, in the sense that typically a user ("host") interac- 

16 tively sends a request to a Web server and receives a response from it, which 

17 is mainly in the form of a document for immediate visual representation in the 

18 user's browser, recently the concept of "Web services" has emerged, accord- 

19 ing to which requests and responses are not (only) interactively sent and re- 

20 ceived by a human user, but rather by another program. For example, an ap- 

21 plication called PowerWarning is designed to monitor a temperature at a cer- 

22 tain remote location and issue a power overload warning if the ambient tem- 

23 perature is above a certain threshold for more than a certain number of con- . 

24 secutive hours. The required weather information is available in a Web page 

25 from a Web server. The application obtains this Web page via the Internet 

26 every hour, extracts the pertinent temperature from it and tests whether the 

27 warning condition is fulfilled (see H: Maruyama et al.: XML and Java, Develop- 

28 ing Web Applications Addison-Wesley, 1999, pp. 8-10). To call the Web ser- 

29 vice and extract the required information from its response, a suitable inter- 

30 face has to be provided, which is typically implemented as a part of the calling 

31 application. In order to facilitate the implementation of interfaces for Web ser- 

32 vices, several standards of Web services have emerged, such as XML (Exten- 
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1 sible Markup Language), SOAP (Simple Access Object Protocol), UDDI (Uni- 

2 versal Description, Discovery and Integration) and WSDL (Web Services De- 

3 scription Language). 

4 A field in which applications typically call other applications or services is 

5 the field of business applications. Special callable applications or services 

6 (which may be, but do not have to be Web services) for which the computer 

7 program products and methods described herein may, for example, be used 

8 are transaction tax-related applications and services. The use of transaction 

9 tax-related applications and services is, however, not mandatory, and software 

10 applications relating to other fields may likewise be linked by the interfaces 

11 described herein. 

12 Besides an income tax system which imposes income-related tax liabili- 

13 ties on individuals and corporations, most countries have a transaction tax 

14 system. A transaction tax liability is induced by an individual commercial 

15 transaction, such as the sale of a good, the purchase of a service or the like. 

16 Typically, the transaction tax is a certain percentage of the price of the goods 

17 or service. Normally, the transaction tax is collected by the vendor or service 

18 provider, who pays the accumulated transaction tax at certain time intervals 

19 (e.g. monthly) to a tax authority (for the sake of simplicity, the following de- 

20 scription only mentions the purchase of goods, but is likewise directed to the 

21 provision of services etc.). 

22 Across the world, there are mainly two different transaction tax systems: 

23 sales and use tax and value added tax (VAT). In a sales and use tax system, 

24 which is imposed in most states throughout the United States, the tax amount 

25 is derived by applying the tax rate to the retail sales price of tangible personal 

26 property or certain enumerated services. If a product is manufactured and sold 

27 in a supply chain, all transactions are non-taxable re-sales until a final retail 

28 sale to an end-user, which is taxable unless the end-user can claim an exemp- 

29 tion from the tax. Thus, in a sales and use tax system, no tax is applied to a 

30 product until it is sold at retail. In a value added tax system, which is applied 

31 in many European countries, the transaction tax in a single individual step in a 

32 supply chain corresponds only to a percentage of the value added in this step, 
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1 i.e. to the difference between the amount of money the vendor receives for 

2 the sold product and the taxable amount he had to spend in order to manufac- 

3 ture or provide the good. In such a value-added tax system, the amount of 

4 transaction tax accumulated over all the steps of the supply chain is independ- 

5 ent of the number of transactions in the chain, it only depends on the price of 

6 the finished product. However, normally the "added value" is not determined 

7 in individual transactions. Rather, every vendor accumulates, on the one hand, 

8 the tax received from buyers and, on the other hand, the tax he has paid to 

9 other vendors for all the transactions occurring within certain time periods 

10 (e.g. months) and pays only the difference between these two accumulated 

11 values to the tax authority. Therefore, also in a value added tax system, when 

12 looking at an individual transaction, the buyer has to pay a certain percentage 

13 of the product's price to the vendor. 

14 Besides these principal differences between sales-and-use tax and value- 

15 added tax, the transaction tax regulations vary from country to country, and, 

16 in the United States, from state to state even down to the level of cities and 

17 areas. For example, there are different rates in different countries and even in 

18 different states. In addition, the tax rate may depend in a particular country or 

19 state specific way on the vendor's place of business and/or the buyer's domi- 

20 cile and/or the origin and/or the destination of the good when it is shipped 

21 from the vendor to the buyer. In many countries there is a tax rate of zero for 

22 exported goods. However, in trade within the European Union, transaction tax 

23 has to be paid in the country where the transaction takes place, but is then 

24 credited to the destination country in a clearing procedure carried out by the 

25 tax authorities. Also the requirements for transaction tax-related bookkeeping, 

26 reporting and the form and period of tax declarations to the tax authorities 

27 generally vary from country to country. 

28 Nowadays, big companies often have worldwide business coverage, i.e. 

29 they conduct business in far more than 100 countries with a large proportion 

30 of cross-border transactions. In view of the ever-growing internationalization 

31 and globalization of enterprises and trade, computerized systems have been 

32 designed which enable enterprises to fulfill the different transaction tax liabili- 
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1 ties in an efficient way. There are already hundreds of different transaction-tax 

2 software solutions worldwide. 

3 In one type of solution, a business application, such as an enterprise re- 

4 source planning (ERP) application (which traditionally provides for accounting, 

5 manufacturing logistics, supply-chain management, sales-force automation, 

6 customer service and support, human resources management, etc.) also en- 

7 ables the user to deal with the transaction taxes. For example, the ERP prod- 

8 uct R/3 by SAP provides a facility for transaction tax calculation. In most solu- 

9 tions of this type, the business application and the transaction tax-related 

10 parts of the solution are closely linked to the business application provider's 

11 proprietary technology. 

12 Another type of solution is a specialized application for transaction tax 

13 calculation and/or reporting. Examples of such applications are "TaxWare", 

14 "Sabrix", "Vertex" and "Datev". Normally, each of these solutions requires its 

15 own interface, and many solutions of this type do not provide global coverage. 

16 Consequently, in practice, enterprises with worldwide coverage rely on a vari- 

17 ety of different localized transaction-tax IT systems, which implies an effort to 

18 maintain each system individually. This leads to considerable maintenance 

19 costs and losses due to misconfiguration. In many cases, transaction tax ex- 

20 perts need to handle a large variety of different IT systems of this kind. This 

21 often prevents them from taking the full advantage of their expertise in the 

22 optimization of transaction tax liabilities. 

23 Further examples of transaction-tax software solutions are disclosed in U.S. 

24 patent No. 5,335,169 assigned to DSI, U.S. patent No. 5,987,429 assigned to 

25 SUN Microsystems Inc., U.S. Statutory Invention Registration No. H1,830 as- 

26 signed to The Dow Chemical Company, International publication No. WO 

27 01/16850 A2 (Applicant: Andersen Consulting, LLP), International publication No. 

28 WO 01/35678 A2 (Applicant: ESALESTAX.COM), International publication No. 

29 WO 01/41552 A2 (Applicant: Taxwear International, Inc.), International publication 

30 No. WO 01/97150 A1 (Applicant: Dryden Matrix Technologies, LLC) and Sabrix: 

31 TaxBay Architecture Guide, Version 3.0, 25 July 2001 . 



32 
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1 SUMMARY OF THE INVENTION 
2 

3 The invention is directed to a computer program product including pro- 

4 gram code, when executed on a computer system, for providing an interface 

5 between a calling application and at least one callable application. The pro- 

6 gram code represents a computer program which implements at least two 

7 controllers which cooperate with each other and are at different hierarchical 

8 levels. The controllers are instances of a generic controller. 

9 According to another aspect, a computer program product is provided in- 

10 eluding program code, when executed on a computer system, for providing an 

11 interface between a calling application and at least one callable application. 

12 The program code includes an interface architecture component. The interface 

13 architecture component comprises: an input/output module; an input parser; a 

14 universal state machine; a knowledge base module; a process slip module; a 

15 process carrier. 

16 According to another aspect, a software-implemented method of interfac- 

17 ing a calling application and at least one callable application is provided. The 

18 method comprises: using at least two software-implemented controllers at dif- 

19 ferent hierarchical levels; performing, with the controllers both at the higher 

20 and lower hierarchical levels, a sequence of steps comprising: upon receipt of 

21 an input request from a higher hierarchical level element (which is the calling 

22 application or a controller at a higher hierarchical level), performing input re- 

23 quest handling, sending at least one output request to at least one lower hier- 

24 archical level element (which is a controller at a lower hierarchical level or the 

25 at least one callable application), receiving an input response to the at least 

26 one output request from the lower hierarchical level element, and sending an 

27 output response to the higher hierarchical level element. The output request of 

28 the controller at the higher hierarchical level is the input request to the control- 

29 ler at the lower hierarchical level, and the output response of the controller at 

30 the lower hierarchical level is the input response to the controller at the higher 

31 hierarchical level. 

32 According to a another aspect, a method of implementing a programmed 
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1 interface between a calling application and at least one callable application is 

2 provided. The method comprises: coding at least two controllers at different 

3 hierarchical levels, wherein said controllers are instances of a generic control- 

4 ler. 

5 According to another aspect, a computer program product is provided in- 

6 eluding program code, when executed on a computer system, for providing an 

7 interface between a calling application and at least two transaction-tax calcu- 

8 lation applications. The interface is arranged to carry out, when called by the 

9 calling application, at least one of: selecting one of the transaction-tax calcula- 

10 tion applications depending on a transaction attribute, calling the selected 

11 transaction-tax calculation application and receiving a response from the called 

12 transaction-tax calculation application; and calling at least two of the transac- 

13 tion-tax calculation applications, comparing the responses returned by them. 

14 According to still another aspect, a software-implemented method of in- 

15 terfacing a calling application and at least two transaction-tax calculation ap- 

16 plications is provided. The method comprises, when a call is received from the 

17 calling application, at least one of: selecting one of the transaction-tax calcula- 

18 tion applications depending on a transaction attribute, calling the selected 

19 transaction-tax calculation application and receiving a response from the called 

20 transaction-tax calculation application; and calling at least two of the transac- 

21 tion-tax calculation applications and comparing the responses returned by 

22 them. 
23 

24 DESCRIPTION OF THE DRAWINGS 
25 

26 Embodiments of the invention will now be described, by way of example, 

27 and with reference to the accompanying drawings, in which: 

28 Fig. 1 is a diagram illustrating the internal overall process flow in an em- 

29 bodiment of an interface; 

30 Fig. 2 is a diagram illustrating an exemplary data flow between the calling 

31 and called applications and the interface and within the interface; 

32 Fig. 3 is a high-level architecture diagram of an embodiment of the inter- 
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1 face; 

2 Fig. 4 illustrates an exemplary asynchronous logging procedure; 

3 Fig. 5 shows a simplified class diagram of the embodiment of the inter- 

4 face in UML notation; 

5 Fig. 6 is a high-level architecture diagram of an embodiment of a generic 

6 architecture component of the interface; 

7 Fig. 7 illustrates an embodiment of a process flow in a solution controller; 

8 Fig. 8 illustrates an embodiment of a process flow in a calculation con- 

9 troller; 

10 Fig. 9 illustrates an embodiment of a process flow in a logging controller; 

11 Fig. 10 is a flow diagram illustrating of an embodiment of a country- 

12 specific selection of a called tax calculation application; 

13 Fig. 1 1 is a flow diagram illustrating an embodiment of a process in 

14 which more than one tax calculation application is called; 

15 Fig. 12 illustrates another embodiment of an interface; 

16 Fig. 13 shows a diagrammatic representation of a machine in exemplary 

17 form of a computer system within which a set of instructions, for causing the 

18 machine to perform any of the methodologies discussed herein, may be exe- 

19 cuted. 
20 

21 DESCRIPTION OF THE PREFERRED EMBODIMENTS 
22 

23 Fig. 1 illustrates the internal overall process flow in an embodiment of an 

24 interface. Before proceeding further with the description of Fig. 1, however, a 

25 few items of the embodiments will be discussed. 

26 The preferred embodiments of the computer program product include any 

27 machine-readable medium that is capable of storing or encoding program code 

28 for execution by a computer system. The term "machine-readable medium" 

29 shall accordingly be taken to include, but not to be limited to, solid state 

30 memories, optical and magnetic storage media, and carrier wave signals. The 

31 program code may be machine code or another code which can be converted 

32 into machine code by compilation and/or interpretation, such as source code in 
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1 a high-level programming language or virtual-machine code. 

2 In some of the embodiments, general architecture components or "con- 

3 trollers" are functional components implemented by software. The hardware 

4 on which the software (or program code) is executed so as to provide the con- 

5 trollers may be a computer system, for example including a processor and a 

6 main memory which communicate with each other via a bus, as well as a disc 

7 drive unit, a network interface device and input/output units (such as a video 

8 display unit, an alpha-numeric input device and a cursor control device). The 

9 program code may be stored on the disc drive unit, within the main memory 

10 and/or the processor and may be transmitted or received via the network inter- 

11 face device. In some embodiments, the entire program code may be distrib- 

12 uted over several processors or computers. For example, each controller may 

13 run on a distinct computer. An architecture use of at least two controllers in- 

14 herently enables distributed processing. In other embodiments the program is 

15 integrated in a single computer. 

16 In some of the embodiments, the interface coordinates the processing to 

17 be carried out in response to a call by the calling application. For example, the 

18 interface determines what sequence of steps is to be performed, based on 

19 "event type" information it receives as a parameter of the call. Thus, the call- 

20 ing application requires no knowledge of calling sequences for different event 

21 types. Accordingly, the interface decouples the calling application from the 

22 called applications and thereby also decouples the processes implemented by 

23 the called applications (which, for example represent business processes) from 

24 the processes implemented by the called application. 

25 In some of the embodiments, at least two controllers are at different hi- 

26 erarchical levels. Since they co-operate with each other, the controller at the 

27 higher hierarchical level is superordinate to the controller at the lower hierar- 

28 chical level. For example, the higher hierarchical level controller outputs re- 

29 quests or tasks which form an input to the lower hierarchical level controller. 

30 The lower hierarchical level controller follows such a request or task, e.g. by 

31 returning a response to the higher hierarchical level controller. However, in 

32 some of the embodiments with more than two controllers, not all of them are 
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1 at different hierarchical levels. Rather, they may form a tree-like structure in 

2 which some of the controllers are at the same hierarchical level. For example, 

3 in an embodiment with three controllers, the higher hierarchical level controller 

4 may form the root of the tree and have two children, i.e. subordinate control- 

5 lers, both on the same lower hierarchical level. In other embodiments there are 

6 more than two levels of controllers, i.e. at least one child controller has a 

7 grand-child controller. 

8 In some of the embodiments, the computer program which implements 

9 the controllers has a replicative program structure. On the source code level, a 

10 particular controller is implemented on the basis of a generic program or pro- 

11 gram part defining a "generic controller", which is adapted to the specific 

12 needs of a particular controller and thereby forms an "instance" of the generic 

13 controller. Thus, the interface of some embodiments with replicative structure 

14 is made up of a building block (the generic controller) which is reused so as to 

15 form the instances of at least two controllers co-operating with each other at 

16 the different hierarchical levels. 

17 Such a replicative program structure in which the controllers are in- 

18 stances of a generic controller may be achieved in different traditional ways, 

19 for example, when coding the computer program of the interface, by copying 

20 program code representing the generic controller several times and adapting 

21 each copy so as to represent an instance of the generic controller, or by im- 

22 plementing the generic controller in the form of a generic function or proce- 

23 dure which is callable with a set of parameters which effectively adapt the 

24 generic controller so as to form an instance, and by calling this generic func- 

25 tion or procedure with appropriate instance-related parameters. However, in 

26 other embodiments, another technique is used to generate the replicative pro- 

27 gram structure, which is based on the "inheritance" feature of object-oriented 

28 program languages (see, for example, Cay Horstmann: Computing Concepts 

29 with JAVA 2 Essentials, 2 nd edition, John Wiley and sons, 1999, pp. 341 to 

30 380). In some of these embodiments, the computer program is thus written in 

31 an object-oriented programming language (such as JAVA or C++), and the 

32 generic controller is a class, and the instances of the generic controller are 
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1 subclasses inherited from the generic controller class. In the terminology of 

2 object-oriented programming, a class from which a subclass is inherited is also 

3 called the "superclass" of the subclass. Some object-oriented programming 

4 languages (such as C++) enable a subclass to have more than one super- 

5 class, which is known as multiple inheritance. Other object-oriented program- 

6 ming languages (such as JAVA) do not allow multiple inheritance, but retain 

7 most of its benefits by limiting all but one of the superclasses to a restricted 

8 form by using "interfaces" instead of superclasses. Methods in an interface 

9 are abstract; that is they have a name, parameters and a return type, but they 

10 do not have an implementation. In the present context the concept of "inheri- 

11 tance" is meant to also include such "interfaces" with abstract methods; 

12 however, in some of the preferred embodiments, "inheritance" is meant in the 

13 sense of inheritance from a superclass (i.e. the inherited methods are con- 

14 crete; that is they have an implementation). As to "interfaces" in JAVA, see 

15 Horstmann, pp. 362-368. 

16 In the description of the embodiment, the terms "program code" and 

17 "computer program" are used, and it is defined that the program code repre- 

18 sents a computer program. This terminology is used since the program code 

19 included in the computer program product is typically (but not exclusively) 

20 machine code or virtual-machine code, whereas the computer program is typi- 

21 cally (but not exclusively) written in a high-level programming language. Thus, 

22 the "program code" and the "computer program" are typically (but not neces- 

23 sarily) not identical, but the program code can be obtained from the computer 

24 program by compilation in a well-defined way, and therefore represents the 

25 computer program. Although the replicative structure with controllers (which 

26 are instances of a generic controller) is typically implemented by source code, 

27 i.e. at the level of the "computer program", it will, at least to a certain extent, 

28 be mapped to the machine code i.e. to the "program code", in the compilation 

29 procedure. Thus the replicative structure with co-operating controllers (which 

30 are instances of a generic controller) at different hierarchical levels will at least 

31 be partly present in the machine code. 

32 In some of the embodiments with a replicative controller arrangement, 
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1 this arrangement does not only show up as replicative structure in the com- 

2 puter program and the program code, but also as a replicative sequence of 

3 steps, since the process sequence carried out by the controllers is similar due 

4 to their common descent from the generic controller. The controllers at both 

5 the higher and lower hierarchical levels perform a sequence of steps in which a 

6 controller receives an (input) request from a superordinate element (which may 

7 be a calling application if the considered controller is the higher hierarchical 

8 controller, or an (output) request from the higher hierarchical controller if the 

9 considered controller is the lower hierarchical controller), and the input request 

10 is then handled. Then, optionally, depending on the results of the request han- 

11 dling, one or more output requests are sent to at least one lower hierarchical 

12 level element (which is a controller at a lower hierarchical level if the consid- 

13 ered controller is a lower hierarchical controller, or a callable application, if the 

14 considered controller is a lower hierarchical controller). In reaction to the out- 

15 put request, an input response is then received from the lower hierarchical 

16 element, and, based thereon, an output response is sent to the upper hierar- 

17 chical level element. The interaction between the controllers is such that the 

18 output request of the controller at the higher hierarchical level is the input re- 

19 quest to the controller at the lower hierarchical level, and the output response 

20 of the controller at the lower hierarchical level is the input response to the 

21 controller at the higher hierarchical level. 

22 Such a replicative program structure facilitates the implementation of an 

23 interface between a calling application and at one or more callable applica- 

24 tions. Therefore, the described embodiments also disclose a method of imple- 

25 menting such an interface. The method includes coding at least two control- 

26 lers at different hierarchical levels, wherein the controllers are instances of a 

27 generic controller, as explained above. 

28 In some of the embodiments, a calling application may be a business ap- 

29 plication, such as a commercial-transaction application (wherein the "commer- 

30 cial transaction" may be, for example, the sale of goods or services) or an ERP 

31 application, in the framework of which a service provided by a callable applica- 

32 tion is required. 



200206980-1 12 

1 In some embodiments the calling application outputs a batch of calls to 

2 the callable application or applications. In those embodiments, the interface is 

3 arranged to receive and handle batches of service requests ("events") from the 

4 calling application, and also to return responses batch-wise to the calling ap- 

5 plication. Since the interface processes the requests and calls one or more 

6 callable applications event by event, it is provided with buffers for incoming 

7 requests and outgoing responses. In other embodiments, the calling applica- 

8 tion sends requests separately, e.g. event by event. The first alternative is also 

9 called "offline processing", and the second alternative "online processing". A 

10 typical case of offline processing is a business application which processes a 

11 batch of events, without human intervention between individual events. Off- 

12 line processing usually requires high machine capacities since typically large 

13 batches of events have to be processed within relatively short time. Online 

14 processing is carried out if machine calls are issued on an event-by-event ba- 

15 sis, or if the process is user-driven, in the sense that each individual event is 

16 triggered by a user's intervention. Business applications may require online 

17 processing (for example, if a service is immediately required during a sale 

18 transaction) or offline processing (for example, when a report has to be pre- 

19 pared which summarizes information from a large number of transactions). In 

20 other embodiments, the calling application is an online request handling appli- 

21 cation, such as a Web server. The user (or another application) can send a re- 

22 quest for a service provided by the callable application or applications via a 

23 network (i.e. the Internet) to the online request handling application, which 

24 forwards the request to the interface. 

25 In some of the embodiments, the callable application or applications are 

26 transaction-tax service applications or include a transaction-tax service appli- 

27 cation. One of the transaction tax services provided in the preferred embodi- 

28 ments is transaction tax calculation, another one is transaction tax logging. 

29 Therefore, in the described embodiments at least one of the transaction-tax 

30 service applications coupled to the interface is a transaction-tax calculation 

31 application and/or a transaction-tax logging application. The transaction-tax 

32 calculation and transaction-tax logging applications are also called transaction 
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1 tax calculation and transaction tax logging "engines" hereinafter. 

2 When the calling application sends a call to the interface, it generally 

3 sends, along with the call, an attribute or attributes to the interface which en- 

4 able the application then called by the interface to provide the required service. 

5 The attribute may be data (i.e. in the form of a document) or a pointer to 

6 stored data which is assessable by the interface or the called application. In 

7 embodiments in which the called application is a transaction-tax service appli- 

8 cation, the attribute data of a call (which refers to a particular commercial 

9 transaction) may include an indication of the price paid in the transaction, the 
10 nature of the transaction, the place and time of the transaction and the per- 
il sons or entities involved in the transaction. 

12 A transaction-tax calculation engine calculates the amount of transaction 

13 tax to be paid for a given transaction. In principle, it would be sufficient to 

14 couple the interface to only one transaction-tax calculation engine, if this en- 

15 gine enabled the transaction taxes for all transactions occurring in a particular 

16 context to be correctly calculated. However, a worldwide coverage of transac- 

17 tions of all different types is at least presently hardly achievable in a satisfac- 

18 tory way by means of only one transaction-tax calculation engine, since the 

19 available transaction-tax calculation engines tend to lay the emphasis on par- 

20 ticular countries or regions and/or particular transaction types. Therefore, in 

21 some embodiments, two or more transaction-tax calculation engines may be 

22 called by the interface. 

23 In some of the embodiments with more than one transaction-tax calcula- 

24 tion engine, when the interface is called by the calling application, it selects 

25 one of the transaction-tax calculation engines depending on transaction data 

26 received with the call. For example, if the transaction is a sale of goods in the 

27 U.S. or EU (European Union) (which is indicated by a corresponding country 

28 code included in the transaction data) the interface selects the transaction-tax 

29 calculation engine from those available which enables the transaction tax to be 

30 correctly calculated for a sale in the U.S. or EU, respectively. The interface 

31 then calls the selected transaction-tax calculation engine and receives the cal- 

32 culated transaction tax as a response from it. 
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1 In other embodiments with more than one transaction-tax calculation en- 

2 gine, the interface does not select and call only one transaction-tax calculation 

3 engine for a given transaction, but rather calls more than one transaction-tax 

4 calculation engine for the given transaction, and correspondingly receives more 

5 than one response. The interface then compares and handles these responses, 

6 preferably according to rules which can be implemented by a user. For exam- 

7 pie, the interface may ascertain that the tax amounts provided by the two (or 

8 more) called transaction-tax calculation engines are equal, but in the event that 

9 they are not equal, it may select the response which indicates the lowest tax 

10 amount. 

11 In some embodiments, both of the above-described alternatives are com- 

12 bined. For example, the interface may be coupled to a set of four transaction- 

13 tax calculation engines which has two subsets, each with two engines for tax 

14 calculation in the U.S. or the EU, respectively. In such an embodiment the in- 

15 terface selects for a given transaction one of the two subsets, then calls the 

16 two transaction-tax calculation engines of the selected subset, and compares 

17 the results returned by them. 

18 Another transaction-tax service application called by the interface of 

19 some of the embodiments is a transaction-tax logging application. Most legal 

20 systems require transaction data of tax-relevant transactions to be recorded or 

21 "logged" on a transaction-by-transaction basis. In addition to such legal report- 

22 ing requirements, big enterprises often have internal financial reporting needs 

23 for tax optimization on a global basis. The logging application of these em- 

24 bodiments includes or is coupled to a database or a data warehouse (see short 

25 explanation of "Data warehouses" in D. Messerschmitt: Understanding net- 

26 worked applications, Morgan Kaufmann Publishers 2000, pp. 83-84). Usually, 

27 data can only be entered asynchronously into a data warehouse. Therefore, in 

28 some of the embodiments that use a data warehouse, data output by the in- 

29 terface in order to be logged are first put on a data buffer from where they are 

30 fetched in an asynchronous manner by the logging application and stored in 

31 the data warehouse. The decision of whether a logging has to take place and 

32 what has to be logged (the data to be logged is also called the "logging pay- 
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1 load") is taken by the interface. On the basis of this decision, the interface 

2 constructs the logging payload and outputs it to the logging application. In 

3 most of the embodiments, it is sufficient to use only one logging application. 

4 However, in certain other embodiments it may be desirable to couple the inter- 

5 face to two or more logging applications, e.g. to one logging application for 

6 legal reporting and another one for internal financial reporting. 

7 For some transactions only a transaction-tax calculation application is 

8 called (or more than one transaction-tax calculation engine), for other transac- 

9 tions first a transaction-tax calculation application and then the logging appli- 

10 cation is called. There may be still other transactions, "logging only" transac- 

11 tions, in which no tax calculation is required and only the logging application is 

12 called (for example, if the amount of transaction tax is already known or is not 

13 required for certain transactions). In some of the embodiments, the controller 

14 at the higher hierarchical level is arranged for controlling the overall sequence 

15 of steps carried out by the interface. This controller is also called "solution 

16 controller". It decides whether and in which sequence the controllers at the 

17 lower hierarchical level are invoked. In embodiments also having lower hierar- 

18 chical level controllers, it is, however, not responsible for the control of calls 

19 to the callable applications (e.g. the transaction-tax service applications) cou- 

20 pled to the interface. Rather, the controller or controllers at the lower hierar- 

21 chical level (which are called "calculation controller" and "logging controller" in 

22 the transaction tax-related embodiment) are arranged to control process steps 

23 which are specific to the callable application or applications with which the 

24 respective lower hierarchical level controller is associated. Such callable- 

25 application-specific processing includes, for example, deciding with the calcu- 

26 lation controller which one of two or more country-specific transaction-tax 

27 calculation engines are to be called for a given transaction. Another, simpler 

28 example is just calling a callable application and supplying the output data to 

29 it, e.g. done by the logging controller with the logging payload. 

30 From a point of view of process steps, the controller at the higher hierar- 

31 chical level receives an input request from the calling application and sends an 

32 output request to the controller at the lower hierarchical level. The controller 
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1 at the lower hierarchical level receives the output request of the controller at 

2 the higher hierarchical level, now considered as an "input request", and sends 

3 an output request to the callable application or to one or more of the callable 

4 applications with which it is associated. In turn, it receives an input response 

5 from the called application or applications, and sends an output response to 

6 the controller at the higher hierarchical level. The controller at the higher hier- 

7 archical level receives this output response (now called "input response"). In 

8 some of the embodiments in which the controllers are instances of a generic 

9 controller, the instances of the controllers comprise one or more of the follow- 

10 ing components: an input-output module, and input parser, a validation engine, 

11 a universal state machine, a knowledge base module, a process slip module, 

12 and a process carrier. The input-output module provides an interface to other 

13 controllers or calling or callable applications. The input parser extracts informa- 

14 tion from the incoming data flow. The validation engine performs a validity 

15 check according to the service called, the state in the universal state machine 

16 and the data provided with the call. The knowledge base module keeps the 

17 information about the order of the process steps to be carried out and may 

18 also store high-level service information. The process slip module keeps track 

19 of the different process steps that a request has already passed. Besides keep- 

20 ing this information, the process slip module may provide a resolution between 

21 externally used identifiers and one unique identifier for the present call, i.e. it 

22 acts as an identification reference unit. The process carrier keeps request- 

23 related input and output data while the processing is not yet completed. The 

24 universal state machine coordinates the internal processing flow. It accesses 

25 the knowledge base module and the process slip module, and determines the 

26 next process step according to the internal state and guarantees a successful 

27 completion of the respective data in the process carrier by invoking the appro- 

28 priate actions. 

29 In some embodiments the interface does not have several cooperating 

30 controllers at different hierarchical levels which are instances of generic con- 

31 troller. Some of these embodiments, however, use an interface architecture 

32 component similar to the controllers described above, which includes an in- 
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1 put/output module, an input parser, a universal state machine, a knowledge 

2 base module, a process slip module, and a process carrier. In some of these 

3 embodiments it further includes a validation engine for ascertaining the validity 

4 of calls received by the interface. 

5 Other embodiments of the interface without several controllers at differ- 

6 ent hierarchical levels which are instances of a generic controller are associ- 

7 ated with at least two transaction-tax calculation engines and are arranged to 

8 select one of the transaction-tax calculation applications depending on the at- 

9 tribute data, which is, for example, received along with a call from the calling 

10 application. The interface sends a call to the selected transaction-tax calcula- 

11 tion engine and, thereupon, receives a response from it. In other embodiments 

12 two or more transaction-tax calculation engines are called for one and the 

13 same event, and the responses return by them are compared. 

14 As has already been described above, selecting a suitable transaction-tax 

15 calculation engine and/or calling more than one transaction-tax calculation en- 

16 gine and comparing the returned responses may advantageously (but not nec- 

17 essarily) be combined with interfaces having controllers at different hierarchi- 

18 cal levels and/or with one interface architectural component as described 

19 above. 

20 Returning now to Fig. 1, it illustrates the internal overall process flow in 

21 an interface 1. The interface 1 receives in step S1 a request for a transaction 

22 tax service (an "event") from a calling application 2 (which is for example a 

23 business application or an online request handling application). In step S2, an 

24 input parser extracts information from the incoming data flow associated with 

25 the request (also called "interface request payload"). In step S3 it is ascer- 

26 tained whether a transaction tax calculation is to be carried out for the present 

27 service request. The answer depends on the particular event: for example, if 

28 the call from the calling application or the data attached to it indicates that no 

29 calculation, but only logging is to be carried out or if the data does not allow 

30 tax calculation, the answer in step S3 is negative. If, however, the answer is 

31 positive, then in step S4 a tax calculation engine which is appropriate for the 

32 present event is selected from at least two available tax calculation engines 3, 
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1 3'. In step S5, a transaction-tax calculation request is sent to the selected tax 

2 calculation engine 3 or 3 T , together with data required for the transaction tax 

3 calculation (also called "calculation payload"). When the response from the 

4 called tax calculation engine is received together with the calculation result 

5 data (also called "calculation result payload") in step S6, it is ascertained in 

6 step S7 whether logging has to be performed for the present event. Step S7 is 

7 also carried out if the answer in step S3 is negative (i.e. if no tax calculation is 

8 to be carried out). If the answer in step S7 is positive, logging data (also called 

9 "logging payload") is written to a data buffer 29 in step S8, from where it is 

10 asynchronously fetched and stored in a data warehouse 5 in step S9. The data 

11 warehouse 5 embodies the transaction-tax logging application 4, and the data 

12 buffer 29 is an adapter, as is explained in more detail in the context of Fig. 4. 

13 If the logging payload has successfully been written to the data buffer 29 in 

14 step S8, the valid logging of the present event is indicated, e.g. by a valid log- 

15 ging flag (also called "valid logging indication"), in step S10, and a response 

16 with output data (also called "interface response payload") is returned to the 

17 calling application 2 in step S11. The interface response payload includes the 

18 calculated tax amount and the valid logging indication. If the answer in step 

19 S7 is negative, i.e. no logging is carried out, a response is directly sent to the 

20 calling application after the tax calculation in steps S3 to S6; the interface re- 

21 sponse payload includes the calculated tax amount, but no valid logging indi- 

22 cation. 

23 Fig. 2 illustrates the data flow between the calling and called applications 

24 and the interface and within the interface. A generic data model is used within 

25 the interface 1 . In some of the embodiments, data is internally transferred in 

26 the form of XML documents. XML Schemas define what data elements are 

27 mandatory or optional. The internal data streams are transmitted within the 

28 interface 1 using HTTP. The calling and called applications may send and re- 

29 ceive data payloads according to other, application-specific data models and 

30 may use other transfer protocols than the one used within the interface 1 . 

31 Adapters 6, 7 between the external applications and the interface 1 convert 

32 the data streams from the internal data model to the external data model(s) 
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1 and vice versa and/or the internal transfer protocol to the external transfer pro- 

2 tocol(s) and vice versa. In some of the embodiments (but not necessarily), the 

3 data transferred through the interface is transaction tax-related data which 

4 represents transaction-related information required for calculating the transac- 

5 tion tax for the present transaction and/or for complying with reporting re- 

6 quirements of tax authorities and internal reporting needs. This generally in- 

7 eludes data identifying the participants of the transaction, the kind of transac- 

8 tion, the country or countries in which the transaction took/takes place, the 

9 price paid/to be paid in the transaction, etc. 

10 In Fig. 2, when the calling application 2, e.g. a business application (such 

11 as SAP-SD), sends a request, e.g. a transaction tax calculation and/or logging 

12 request, to the interface 1 for a particular transaction. An interface request 

13 payload, e.g. transaction tax-related data for this transaction, is transferred 

14 together with the request to the interface 1 . The data flow of the interface 

15 request payload is indicated by "F1" in Fig. 2. The data flow F1 is based on a 

16 data model and/or a transfer protocol specific and typically proprietary to the 

17 calling application 2. The adapter 6 between the calling application 2 and an 

18 interface processing component 8 transforms the incoming data flow F1 into a 

19 data flow F2 based on the internally used generic data model and transfer pro- 

20 tocol. (The interface processing component 8, for example, corresponds to the 

21 assembly of controllers 9, 10 and 1 1 of Fig. 3 or the architecture component 

22 1 17 of Fig. 12.) The interface processing component 8 processes the interface 

23 request payload F2 so as to provide a subset of it (here the "calculation pay- 

24 load"). The subset includes that data which is relevant for the application to 

25 be called, here the transaction tax engine 3. The calculation payload F3 is sent 

26 together with a calculation request to tax calculation engine 3. The adapter 7 

27 transforms the calculation payload F3 according to a data model and/or trans- 

28 fer protocol specific and typically proprietary to the calculation application 3. 

29 The transformed calculation payload is called "F3a". The tax calculation engine 

30 3 may be a Web service, a service provided within an intranet, or a service 

31 provided within the same computer in which the calling application 2 is run- 

32 ning. Together with the subsequent response of the calculation engine 3, the 
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1 calculation result payload F4a which includes the result of the tax calculation 

2 is returned to the interface 1 , again based on the specific data model and/or 

3 transfer protocol of the calculation application 3. The adapter 7 transforms it 

4 into a calculation result payload F4 based on the interface's generic internal 

5 data format. The interface processing component 8 processes the data flow 

6 F4 so as to comply with requirements of the calling application 2, and sends 

7 the result, called interface response payload F7, to the adapter 6 which con- 

8 verts it to the data model and/or transfer protocol of the calling application 2, 

9 and forwards it to the calling application 2 as data flow F1. If logging is re- 

10 quired, the interface processing component 8 combines the interface request 

11 payload F2 from the calling application 2 with the calculation result payload F4 

12 from the calculation application 3 and sends the resulting data flow, the log- 

13 ging payload F5, to the data buffer 29, from where it is asynchronously 

14 fetched and stored in the data warehouse 5. In some embodiments, a valid 

15 logging indication is returned to the interface processing component 8 (data 

16 flow F6) if the logging payload has successfully been deposited in the data 

17 buffer 29. The data buffer 29 is an adapter between the interface processing 

18 component 8 and the warehouse 5. The embodiment shown in Fig. 2 has only 

19 one tax calculation engine, but in other embodiments with more than one tax 

20 calculation engine the data flows correspond to the ones described in connec- 

21 tion with Fig. 2. 

22 Fig. 3 is a high-level diagram of a preferred embodiment of an interface 1 

23 that has a replicative structure. It is based on a generic architecture compo- 

24 nent, also referred to as "generic controller". Several instances of the generic 

25 controller (also referred to as "controllers") are arranged at different hierarchi- 

26 cal levels. In the example of Fig. 3, there are three controllers at two different 

27 hierarchical levels. A controller called solution controller 9 is arranged at the 

28 higher hierarchical level, and two controllers, called calculation controller 10 

29 and logging controller 1 1 are arranged at a lower hierarchical level. The con- 

30 trollers 9, 10, 11 are cascaded (or arranged in a tree-like structure), and con- 

31 trollers at different hierarchical levels co-operate with each other. 

32 In some of the embodiments, the controllers 9, 10, 11 each have only 
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1 one (upper) entry point 12 for their request/response processing, which is an 

2 upper input/output module (see Fig. 6 - "IOM"). In addition, they may have 

3 one or more further entry points constituting a user interface, e.g. for simula- 

4 tion, set-up, tests, maintenance, etc. The controllers 9, 10, 11 also have one 

5 or more (lower) exit points 13, which are lower input/output modules 13 (see 

6 Fig. 6 - "IOM"), one for each lower hierarchical level controller 10, 11 or call- 

7 able application 3, 4, respectively. 

8 The solution controller 9 is arranged to process a request, e.g. transac- 

9 tion-tax service request received from the calling application 2 via the adapter 

10 6 and the entry point 1 2. It decides on the basis of the request and/or the data 

11 associated with it whether the calculation controller 10 or the logging control- 

12 ler 1 1 or both are to be called, and, if the latter case applies, in what se- 

13 quence they are to be called, and performs the call(s) via the respective exit 

14 point 13. It also forms subsets of and combines data, as was explained with 

15 reference to Fig. 2. 

16 On the lower hierarchical level, one controller is provided for each type of 

17 service, i.e. a calculation controller 10 and a logging controller 11. They com- 

18 municate with the superordinate solution controller 9 via their respective entry 

19 points 12. The task of the lower hierarchical level controllers 10, 11 is to 

20 process a call of the solution controller 9 and to forward a suitable call to a 

21 service application 3, 4 via one of their exit points and adapters 7, 14. If more 

22 than one service application 3, 3' can be called by a controller, as is the case 

23 with calculation controller 10, the controller also decides which one of the 

24 service applications 3, 3' is to be called. For example, in the case of transac- 

25 tion tax calculation, the decision may be taken on the basis of the country to 

26 which the present transaction relates. The calculation controller 10 receives 

27 the responses from the called service applications 3, 3' via the corresponding 

28 exit point 13 and processes and forwards them to the solution controller 9. In 

29 embodiments in which more than one service application 3, 3' may be called 

30 for one and the same transaction, the calculation controller 10 also compares 

31 the results returned from the called service applications 3, 3', consolidates the 

32 two or more results (e.g. by choosing the one which indicates the lowest 
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1 transaction tax) and forwards the consolidated result to the solution controller 

2 9. 

3 When the logging controller 1 1 is called by the solution controller 9, it 

4 forwards a corresponding logging request together with the data to be logged, 

5 the logging payload, to the data warehouse 5 via its exit point 13 and a log- 

6 ging adapter 14, which is explained in more detail in Fig. 4. Typically, no re- 

7 sponse data is returned from the data warehouse 5 or adapter 14, except a 

8 valid logging indication. Correspondingly, the logging controller 12 does not 

9 return any response data to the solution controller 9 except for a valid logging 

10 indication. 

11 The solution controller 9 processes the responses and response data re- 

12 turned from the calculation controller 10 and/or logging controller 11 and re- 

13 turns a corresponding response to the calling application 2 via the entry point 

14 12 and adapter 6. 

15 Turning now to Fig. 4, since data logging in a persistent storage is a per- 

16 formance-heavy process, typical data warehouses (such as the "SAP Business 

17 Warehouse") do not enable synchronous ("online") logging. On the other hand, 

18 some embodiments of the interface 1 require logging requests to be processed 

19 as they appear, i.e. synchronously. Fig. 4 illustrates an embodiment of an 

20 adapter 14 (Fig. 3) and the logging process by which a bridging between the 

21 interface's synchronous and the data warehouse's asynchronous environments 

22 is provided. The logging controller 1 1 sends a logging request together with 

23 the logging payload ("LP" in Fig. 4) to an adapter (referred to as "adapter 14" 

24 in Fig. 3) composed of a data buffer 29, an asynchronous logging client 15 

25 and a data base 16. The logging payload - which is e.g. in the form of an XML 

26 document - is synchronously dropped in the data buffer 29. The asynchronous 

27 logging client 1 5 fetches the logging payload from the data buffer 29 in an 

28 asynchronous way. Thus, the data buffer 29 and the client 1 5 represent a 

29 bridge between the synchronous and asynchronous environments. The control 

30 of this bridge and communication across the bridge may be based on a mes- 

31 sage service, such as the Java Message Service (JMS). The client 15 forwards 

32 the fetched data to the database 1 6 from where it is entered or fetched into 
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1 the data warehouse 5. The message service is configured to ensure that no 

2 transaction data sent for logging gets lost. In some embodiments, a valid log- 

3 ging indication is (synchronously) returned to the logging controller 1 1 when 

4 the logging payload has successfully been deposited in the data buffer 5. 

5 Fig. 5 shows a simplified class diagram of the interface 1 in UML (Unified 

6 Modeling Language) notation. The boxes shown represent classes imple- 

7 mented in an object-oriented programming language. A GenericController class 

8 1 7 is a superclass of the other classes shown in Fig. 5. Three subclasses of 

9 the GenericController class 1 7 are the SolutionController class 1 8, Calcula- 

10 tionController class 19 and LoggingController class 20. They implement the 

11 solution controller 9, calculation controller 10 and logging controller 1 1 of Fig. 

12 3. There is an inheritance relationship between the superclass 17 and the sub- 

13 classes 18, 19, 20, i.e. the subclass 18, 19, 20 inherit from the superclass 

14 17. In the JAVA programming language, the inheritance relationship is, for 

15 example, defined by the keyword "extends". Inheritance enables code to be 

16 reused: by inheriting from the superclass 17, methods and variables defined in 

17 it are available in the subclasses 18, 19, 20. The subclasses 18, 19, 20 may 

18 use these methods and variables inherited from the superclass 17 and can fur- 

19 ther be adapted to their specific needs by defining special subclass methods 

20 and variables and by overriding inherited superclass methods. Thus, in the per- 

21 spective of the superclass, properties common to the subclasses 18, 19, 20 

22 are collected in the generic controller superclass 17. 

23 Fig. 6 is a high-level architecture diagram of the generic architecture 

24 component or "generic controller" 21 represented by the GenericController 

25 class 17 in Fig. 5. The solution controller 9, calculation controller 10 and log- 

26 ging controller 1 1 of Fig. 3 are instances of the generic controller 21 . 

27 The generic controller is composed of the following functional compo- 

28 nents: Several input/output modules 22 (IOM), an input parser 23 (IP), a vali- 

29 dation engine 24 (VE), a universal state machine 25 (USM), a knowledge base 

30 module 26 (KBM), a process slip module 27 (PSM), and a process carrier 28 

31 (PC). 

32 The input/output modules 22 provide interfaces to calling or called appli- 



200206980-1 24 

1 cations or to other controllers. The embodiment of the generic controller 21 

2 shown in Fig. 6 has one upper input/output module 22 and several lower in- 

3 put/output modules 22, since in many embodiments only one upper entry 

4 point is provided, but several lower exit points, in order to enable more than 

5 one application 3, 4 or controller 18, 19, 20 to be called. In other embodi- 

6 ments with more than one upper entry point, a corresponding number of up- 

7 stream input/output modules 22 are provided. If in an instance of the generic 

8 controller 21 only one application has to be called (as is the case with the log- 

9 ging controller 1 1 in Fig. 3), only one lower input/output module 22 is instan- 

10 tiated. The input/output modules 22 are bi-directional. They pass calls (i.e. 

11 requests) and responses along with call or response attributes, which are, for 

12 example, contained in a document (e.g. an XML document) attached to the 

13 call or response. In some of the embodiments, the input/output module 22 

14 may be arranged to support both online flow and batch flow. To this end it is 

15 provided with a bi-directional online interface, an input buffer for the input 

16 batch flow and an output buffer for the output batch flow. An input/output 

17 module 22 with this functionality may preferably be instantiated as the upper 

18 input/output module 22 of the solution controller 9 which is the interface's 

19 entry point for calling applications 2. 

20 The input parser 23 extracts information from the incoming data flow, 

21 the interface request payload, e.g. in the form of an XML-document attached 

22 to the call. The definition of what information is extracted may depend on the 

23 called service. For example, if the called service is "tax calculation" other in- 

24 formation may be extracted than if the called service is "logging". 

25 The validation engine 24 subsequently performs a validity check of the 

26 extracted information, which may again depend on the called service, and, in 

27 addition, on the data provided and the present state of the universal state ma- 

28 chine 25. For example, a validity check may ascertain whether a called service 

29 is available and whether the call to the service is complete and consistent. 

30 When the generic controller 21 is instantiated, validation is particularly useful 

31 in the upper hierarchical level controller, e.g. the solution controller 9, but can 

32 also be performed in the lower hierarchical level controllers, e.g. the solution 
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1 and calculation controllers 10, 11. However, if performance is critical, the 

2 validation engine 24 can be inactivated or omitted in the upper hierarchical 

3 level controller 9 and in particular in the lower hierarchical level controllers 10, 

4 11, since the latter only receive internal calls from the superordinate higher 

5 hierarchical level controller 9. 

6 The knowledge base module 26 keeps (i.e. stores) the information about 

7 the individual process steps to be performed and the order in which they are 

8 to be performed within the controller 9, 10, 11. Upon request of the process 

9 slip module 27, it returns information characterizing a particular process step 

10 to be carried out to the universal. state machine 25. The knowledge base mod- 

11 ule 26 also stores high-level service information. 

12 The process slip module 27 keeps information about the different process 

13 steps. This information is put down into the process slip assigned to the cur- 

14 rent process (event) in the beginning of the process. The process slip includes 

15 all alternative process paths to enable the universal state machine 25 to carry 

16 out the correct logical sequence. The process slip is restricted to the hierarchi- 

17 cal layer of its controller 9, 10; 11. The process slip is comparable to a state- 

18 transition diagram. The process slip module 27 keeps track of the different 

19 process steps that a processing request has already passed and determines 

20 which process steps are still to be performed in the current process., It re- 

21 quests the knowledge base module 26 to return the required process step in- 

22 formation to the universal state machine 25. Optionally, the process slip mod- 

23 ule 27 also defines a case-dependent data model, i.e. a sub-model of the full 

24 data model, wherein the sub-model definition may depend on the event type, 

25 on the specific application to be called, etc.. According to the sub-model defi- 

26 nition, only a sub-set of the whole data set may be attached to a request or 

27 response. Furthermore, the process slip module 27 provides a resolution be- 

28 tween externally used identifiers and one unique identifier used internally for 

29 each event, e.g. each transaction. Such a unique event identification enables 

30 "interleaved" processing. This means that processing of a new event can start 

31 before the processing of the previous transaction event has been completed, 

32 i.e. before a response from the tax calculation application 3 has been received 
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1 for the previous event. Preferably, for each event a new thread or process is 

2 started, and the event identification then identifies the thread or process as- 

3 signed to a particular event. 

4 The process carrier 28 keeps (i.e. stores) the input and output data asso- 

5 ciated with an event while the processing of the event is not yet completed. 

6 The universal state machine 25 coordinates the internal process flow. It 

7 accesses the knowledge base module 26 and the process slip module 27 and 

8 thereby determines the next process step according to the present internal 

9 state. This guarantees successful completion of the respective task and the 

10 data in the process carrier 28 by invoking the appropriate steps and actions. 

11 In addition to the entry point at the upper input/output module 22, the 

12 generic controller 21 provides another entry point constituting a user interface, 

13 e.g. for simulation, set-up, tests, manual intervention, maintenance, in particu- 

14 lar maintenance of the knowledge, processes and the rules stored in the 

15 knowledge base module 26, etc. 

16 Due to the above-described replicative program structure, not only the 

17 structure of the instances 9, 10, 1 1 of the generic controller 21, but also the 

18 processes carried out by them are similar to each other. This is illustrated by 

19 Figs. 7 to 9, which show the process flow within the solution controller 9, 

20 calculation controller 10 and logging controller 1 1 . 

21 In the solution controller process flow according to Fig. 7, a call from the 



22 calling application 2 is received by the input/output module 22 and forwarded 

23 to the input parser 23 (e.g. an XML parser), which parses the input data in 

24 step P1. The parsed information is then validated by the validation engine 24 

25 in step P2. In step P3, the universal state machine 25 processes the event on 

26 the basis of "business rules" which define the overall processing carried out by 

27 the solution controller 9. For example, in an embodiment, a first business rule 

28 has the following form: 
29 

Event type Calculation Logging Exception? 

required? required? ( = evaluate 

second 
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business rule?) 

Trade order gene- yes no yes 

ration 

Final trade invoice yes yes no 

generation 

1 

2 The first business rule shown in the table above requires transaction tax 

3 calculation to be performed, i.e. the calculation controller 10 be called for both 

4 event types that are expressly mentioned in the table. However, logging is 

5 only required, i.e. the logging controller 1 1 is only called, for the event type 

6 "Final trade invoice generation", but is not required for the event type "Trade 

7 order generation". However, in the case of a "Trade order generation" event 

8 an "Exception" flag is set, which means that a second business rule is evalu- 

9 ated. By contrast, for the other event type, "Final trade invoice generation", 

10 the exception flag is not set, i.e. for those events of that type the second 

11 business rule is not evaluated. There may be other event types for which log- 

12 ging is only required ("logging only" transactions). 

13 An example of the second business rule is: 
14 

Transaction event type Country 

Trade order generation ES 

15 

16 According to the above second business rule, if the "Country" of the 

17 transaction is "ES" (Spain) then the solution controller 9 mandates logging 

18 also for "Trade order generation" events, although for this event type logging 

19 is generally not triggered, according to the first business rule. 

20 Further business rules may, for example, perform a conditional check of 

21 the existence of data elements in the input file (e.g. an XML file), if, for exam- 

22 pie, some input data elements are optional for some event types but manda- 

23 tory for others, and the input file validation (e.g. XML-input-file validation) is 
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1 not capable of performing conditional validation. 

2 Depending on the event type and the business rules, the universal state 

3 machine 25 initiates a call to the calculation controller 10 in step P5. Upon 

4 receipt of the calculation controller's 10 response, and depending on the event 

5 type and the business rules, the universal state machine 25 then either returns 

6 the response to the calling application 2 via the input/output module 1 2 in 

7 step P5, or calls the logging controller 1 1 in step P6. For "logging only" events 

8 the logging controller 6 is only called. The logging controller 6 returns a con- 

9 firmation that the logging has been successfully completed (a valid logging 

10 indication), whereupon the result included in the calculation controller's 10 

11 response and, optionally, a valid logging indication are returned to the calling 

12 application in step P7. 

13 Fig. 8 illustrates the process flow in the calculation controller 10. A call 

14 from the superordinate solution controller 9 is received by the input/output 

15 module 12 in step P 11 and is then directly processed by the universal state 

16 machine 25 in step P14. An optional intermediate validation step is omitted in 

17 the embodiment shown in Fig. 8 since the calculation controller 10 is only in- 

18 ternally called by the superordinate solution controller 9 - the same applies to 

19 the process flow of the logging controller 1 1 shown in Fig. 9. In the process- 

20 ing step P14, mainly one of several tax calculation engines 3, 3' is selected by 

21 selection rules. For example, a certain tax calculation application 3, 3' may be 

22 assigned to one or more certain transaction countries. For a particular event 

23 with a particular transaction country indicated by the calculation request pay- 

24 load, the tax calculation engine assigned to the particular transaction country is 

25 selected from engines 3, 3'. The selected tax calculation application 3, 3' is 

26 then called in step P1 5, P15\ The response received from it is returned to the 

27 solution controller 9 via the input/output module 1 2 in step P17. 

28 Fig. 9 illustrates the process flow in the logging controller 1 1 . A call from 

29 the superordinate solution controller 9 is received by the input/output module 

30 1 2 in step P21 and is then directly processed by the universal state machine 

31 25 in step P24. The processing includes, for example, validating the data to be 

32 logged (the logging payload) on the basis of logging-related rules. Such a vali- 
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1 dation step is preferably included in the logging controller's processing in order 

2 to still ascertain in the "synchronous region" whether all data elements man- 

3 datory for logging are present. If such a validation were instead performed in 

4 the "asynchronous region" it would be difficult to signalize the absence of a 

5 mandatory data element. In principle, the logging validation may also be per- 

6 formed by the solution controller 9, which is a possible, but more complex so- 

7 lution. Thereupon, a logging request is sent to the logging data buffer 29 in 

8 step P25. A confirmation that the logging has been successfully completed is 

9 returned to the logging controller 1 1 and forwarded to the calling solution con- 

10 troller 9 via the input/output module 21 in step P27. 

11 Fig. 10 is a flow diagram illustrating an embodiment of a country-specific 

12 selection of a tax calculation engine 3. In the embodiment of Fig. 10, the in- 

13 terface 1 is enabled to send tax calculation requests to three different tax cal- 

14 culation engines: a U.S. tax calculation engine 3, an EU tax calculation engine 

15 3' and a tax calculation engine 3" for other countries. In embodiments with a 

16 dedicated calculation controller 10 (such as the ones described in connection 

17 with Figs. 3 to 9), country-specific selection is performed by the calculation 

18 controller 10. In step T1 , it receives a call from the superordinate solution con- 

19 troller 9 together with the interface request payload which includes data char- 

20 acterizing the current event to be processed, in particular including a country 

21 code of the country relevant for the event. In step T2 it is ascertained whether 

22 the country code is "US". If the answer in step T2 is positive, the U.S. tax 

23 calculation engine 3 is called in step T3. The call is accompanied by data re- 

24 quired for the tax calculation (the calculation request payload). If, however, 

25 the answer in step T2 is negative, it is ascertained in step T4 whether the 

26 country code is "EU". If the answer is positive, the EU tax calculation engine 

27 3' is called in step T3\ If, however, the answer in step T4 is negative, the tax 

28 calculation engine 3" is called in step T3". In step T5, the calculation control- 

29 ler 10 waits for a response from the called calculation engine 3, 3' or 3". 

30 When the response is received in step T6 together with result data (the calcu- 

31 lation response payload), the calculation controller 10 returns a response to 

32 the calling application controller 9 together with response data (the interface 
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1 response payload) in step T7. 

2 Fig. 1 1 is a flow diagram of another embodiment in which more than one 

3 tax calculation are called (here referred to as first tax calculation engine 3 and 

4 second tax calculation engine 3') for one and the same event, also referred to 

5 as "redundant tax calculation". In embodiments with a dedicated calculation 

6 controller 10, as the ones of Figs. 3 to 8, the process illustrated in Fig. 1 1 is 

7 carried out by the calculation controller 10. It receives a call from the su- 

8 perordinate solution controller 9 in step U1. In step U2, it calls the first tax 

9 calculation engine 3 as well as the second tax calculation engine 3\ in step 

10 U3. In step U4, it waits for the responses of the called tax calculation engines 

11 3, 3\ When the responses are received in step U5, the calculation controller 

12 10 compares in step U6 the received results, e.g. it ascertains whether the tax 

13 amounts calculated by the called tax calculation engines 3, 3' are equal. If the 

14 answer is positive, the calculated tax amount is returned in step U7 as a re- 

15 sponse to the request in step U1 to the superordinate solution controller 9. If 

16 the answer is negative, the smaller of the tax amounts received from the 

17 called tax calculation applications 3, 3' is determined in step U8. In step U9, it 

18 is returned as a response to the call in step U1 to the solution controller 9. In 

19 the latter case, in some embodiments an inconsistency flag is set in the re- 

20 sponse data so as to notify the calling solution controller 9 that an inconsis- 

21 tency has been discovered in the redundant tax calculation controlled by the 

22 calculation controller 10. The inconsistency flag can, for example, be used for 

23 testing and debugging purposes. 

24 Fig. 12 illustrates another embodiment of an interface 101 without a rep- 

25 licative structure. The interface 101 receives a call from a calling business ap- 

26 plication 2, sends a request to tax calculation engines 3 and/or 3', combines 

27 the result(s) received from it (them) with data received from the calling busi- 

28 ness application 2 and logs the combined data in a data buffer of an adapter 

29 14 to a data warehouse 5, or returns the result(s) from the calculation engines 

30 3 and/or 3' to the calling business application 2, in a similar way as was ex- 

31 plained in connection with the replicative embodiments described in connec- 

32 tion with Figs. 3 to 9. The external functionality of interface 101 is thus the 
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1 same as the one of the replicative interface in Figs. 3 to 9, in particular the 

2 functionality regarding the country-specific selection of a tax calculation en- 

3 gine illustrated in Fig. 10 and/or the functionality of calling more than one tax 

4 calculation engine, as illustrated in Fig. 1 1. Internally, the interface 101 has no 

5 replicative controller structure, but, in some embodiments, has one interface 

6 architecture component 1 17 which resembles the generic controller 1 7 of Fig. 

7 5. In contrast to the solution controller 9 of Fig. 3, the interface architecture 

8 component 1 1 7 is also responsible for the selection of one of the calculation 

9 engines 3, 3', the consistency check if both tax calculation applications 3, 3' 

10 are called during one transaction event, and the data verification before the 

11 logging is carried out. Correspondingly, all the business rules described in con- 

12 nection with Figs. 7 to 9 which are distributed over the replicative embodi- 

13 ments over the different controllers 9 to 11, are now combined in the archi- 

14 tecture component controller 1 17. 

15 The interface 101 need not be used for interfacing transaction tax-related 

16 applications. Rather, it may be used as an interface between calling on callable 

17 applications of any other type or for any other purpose. 

18 Fig. 13 shows a diagrammatic representation of a machine in exemplary 

19 form of a computer system 200 within which a set of instructions, for causing 

20 the machine to perform any of the methodologies discussed herein, may be 

21 executed. The computer system 200 includes a processor 201 and memory. 

22 In the example of Fig. 1 3 it is a main memory 202 and a static memory 203, 

23 which communicate with each other via a bus 204. The computer system 200 

24 may include further optional components, such as a video display unit 205, an 

25 alpha-numeric input device 206, a cursor control device 207, a disk drive unit 

26 208 and a network interface device 209. 

27 Further optional components are a disk drive unit 208 which includes a 

28 machine-readable medium 210 on which is stored a set of instructions (i.e. 

29 software) 211 embodying any one, or all, of the methodologies described 

30 above. The software 21 1 is also shown to reside, completely, or at least par- 

31 tially, within the main memory 202 and/or within the processor 201. The 

32 software 211 may further be transmitted or received via the network interface 
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1 device 209. In other embodiments, the software 211 is distributed over sev- 

2 eral processors or computers. For example, each controller may run on a dis- 

3 tinct computer. 

4 Thus, embodiments of interfaces having a replicative structure, embodi- 

5 ments with an architecture component, and embodiments enabling an appro- 

6 priate transaction-tax calculation engine to be selected or to call more than 

7 one calculation engine for one and the same event to be called have been de- 

8 scribed. 

9 All publications and existing systems mentioned in this specification are 

10 herein incorporated by reference. 

11 Although certain methods and products constructed in accordance with 

12 the teachings of the invention have been described herein, the scope of cover- 

13 age of this patent is not limited thereto. On the contrary, this patent covers all 

14 embodiments of the teachings of the invention fairly falling within the scope of 

15 the appended claims either literally or under the doctrine of equivalents. 



